The present invention is related to file transfer software and more specifically to software for verifying proper receipt of transferred files.
When multiple computer files are transferred, it may be helpful to verify that all files were properly received. Should a file be missing, or should an extra file be received, corrective measures may be taken only if some indication of the difference between what was sent and what was received is possible.
Manifests have been used to solve this problem. A manifest may contain a list of the filenames that are sent together. The sender of the files prepares the manifest and sends it with the files. The recipient can use the manifest to identify whether all files sent have been received, and to ensure no extra files are received, such as those that may contain computer viruses.
To ensure the integrity of the files sent and received, the sender can hash each of the files and include the result of each hash in the manifest. The recipient can also hash the files received and compare the hash result produced from the files received with that of the manifest.
If the hash results are the same, it is likely that the file received is identical to the file sent. Otherwise, the file received may be corrupt.
If either the wrong number of files are received, or the hash of the files does not match the hash results in the manifest, the files can be refused by the recipient, and the recipient may request the sender resend the files.
While a conventional manifest has application where the precise number of files is known in advance, in other circumstances, a conventional manifest may not be used. For example, it may be desirable in some circumstances to prepare a manifest containing a superset of-the files that will actually be sent. For example, if different language versions of a computer software application may be transmitted, it may be desirable to prepare a single manifest containing the names and hash results of all files that could be transmitted in all languages, but only transmit one language version of the application with the manifest. Some of the files listed in the manifest may not be transmitted. The recipient of a conventional manifest would reject such files as not precisely duplicating those listed in the manifest.
In other circumstances, it may be desirable to send additional files that are not listed in the manifest at all. For example, user-specific files, such as those that might contain data of an end user of a computer software application may utilize their own authentication techniques. Because each of these files can be unique to the user, including such files in the manifest would require a new manifest for each user. Because the manifest is hashed or otherwise signed by the supplier of the files to ensure integrity, it can be undesirable to trust an automated facility to hash a manifest for each user.
What is needed is a manifest that can allow files to be validated and authenticated that can be used in a wider variety of circumstances than a conventional manifest.
A method and apparatus compares the filenames of files received with the filenames received in a manifest. The manifest contains a policy section describing the rules used to accept or reject files received that may be inconsistent with the manifest. For example, files may be listed in the manifest, but not received, or may be received but not listed in the manifest. The policy section of the manifest may specify that all files are to be received even if some of the files are inconsistent, or that all files are to be received, but only if one type of inconsistency exists, such as files received that are not in the manifest. The manifest may contain hash results of each file to allow for detection in the conventional manner of corruption of files both received and listed in the manifest.